Many applications and services rely on username and password to authenticate a user. The user may be asked to enter his credentials each time he logs in. Sometimes the user's credentials are stored. Some applications access a second application on the user's behalf using a token. For example, a first application (called a “relying party” because the application relies on another entity to authenticate the user) can present the user's credentials to an identity provider. In response to successful authentication, the identity provider can then send the first application a token which the first application can use to access a second application on the user's behalf. Frequently, the second application updates information (e.g., data files) on the client application or device. Ensuring that computer files in two or more locations are updated according to a set of rules is called synchronizing or “syncing”. For example, when a smartphone application accesses an online email provider, the user's inbox is synced with the email provider's inbox for the user by, for example, receiving the user's new emails on the smartphone.
When a user account is locked, applications and devices stop syncing (i.e., data files are not updated). To continue the smartphone example above, the user does not receive his new emails. Typically, the user has to take one or more actions to re-enable sync. Before taking these actions, the user may have to perform other tasks first, such as proving his identity. A number of tests have been devised to attempt to confirm that a user is who he says he is. As one example of many, Captcha is a type of challenge-response test that attempts to ensure that the response is really generated by a person. Another type of test asks a user to provide secondary proof of identity by providing profile information such as birthdate or answers to questions that agree with answers previously provided by the user and saved by the system. Yet another type of test asks a user to provide the one time code that is sent to an email address or mobile phone number previously provided by the user and saved by the system. When the user is able to successfully pass whatever test he is presented with, the account is unlocked. Other user actions such as updating a password may be requested before sync is re-enabled.
Existing synchronization mechanisms can include the programs used to synchronize files and the protocol used by the synchronizing programs. Some communications between applications and devices rely on legacy protocols that do not support rich fault messaging. Examples of protocols that lack rich fault messaging include but are not limited to POP, IMAP, Exchange Active Sync, and certain rich client interfaces used, for example, for email applications embedded into smartphones, smartphone authentication and game console authentication. These legacy client-server communication protocols do not provide built-in support for identification of the cause of the fault. When a problem with the user's account arises, an application or device that uses one of these legacy protocols may provide only a generic error message such as “unable to sync” without giving the user any information about what the problem is or how it can be fixed (remediation). Even if an existing mechanism uses a protocol that is capable of rich fault messaging, the programs that use the rich fault messaging protocol may not make use of its capabilities.